Controller accessible test access port controls

ABSTRACT

Boundary scan test data and a command to initiate a boundary scan test are received via a universal asynchronous receiver-transmitter (UART). Based on receiving the command, a boundary scan test mode is initiated at a memory sub-system controller. A boundary scan test vector based on the boundary scan test data is synchronously streamed to a boundary scan chain. Test result data output by the scan chain is provided to a UART host via the UART.

TECHNICAL FIELD

Embodiments of the disclosure relate generally to memory sub-systemsand, more specifically, to test access port (TAP) controls that areaccessible to a memory sub-system controller.

BACKGROUND

A memory sub-system can include one or more memory devices that storedata. The memory devices can be, for example, non-volatile memorydevices and volatile memory devices. In general, a host system canutilize a memory sub-system to store data at the memory devices and toretrieve data from the memory devices.

BRIEF DESCRIPTION OF THE DRAWINGS

The present disclosure will be understood more fully from the detaileddescription given below and from the accompanying drawings of variousembodiments of the disclosure.

FIG. 1 illustrates an example computing system that includes a memorysub-system, in accordance with some embodiments of the presentdisclosure.

FIG. 2 illustrates a process flow for facilitating post-manufactureboundary scan testing of a printed circuit board (PCB) mounted memorysub-system controller, in accordance with some embodiments of thepresent disclosure.

FIGS. 3 and 4 are flow diagrams of an example method to facilitatepost-manufacture boundary scan testing of a PCB mounted memorysub-system controller, in accordance with some embodiments of thepresent disclosure

FIG. 5 is a block diagram of an example computer system in whichembodiments of the present disclosure may operate.

DETAILED DESCRIPTION

Aspects of the present disclosure are directed to facilitating boundaryscan testing of a printed circuit board (PCB) mounted memory sub-systemcontroller. A memory sub-system can be a storage device, a memorymodule, or a hybrid of a storage device and memory module. Examples ofstorage devices and memory modules are described below in conjunctionwith FIG. 1. In general, a host system can utilize a memory sub-systemthat includes one or more components, such as memory devices that storedata. The host system can provide data to be stored at the memorysub-system and can request data to be retrieved from the memorysub-system.

A memory sub-system controller (referred to hereinafter simply as a“controller”) can receive commands or operations from the host systemand can convert the commands or operations into instructions orappropriate commands to achieve the desired access to the memorycomponents. After manufacture of a controller on a PCB, controllerstructure and functionality are tested and verified. Joint Test ActionGroup (JTAG) is an industry standard for verifying designs and testingPCBs after manufacture. JTAG specifies use of a dedicated debug port toimplement a serial communications interface (also referred to herein asa “JTAG interface” or “JTAG port”) that provides access to a controllerwithout requiring direct external access to the system address and databuses. The interface connects to an on-chip test access port (TAP)controller that implements a stateful protocol to access a set of testregisters. JTAG also includes a specification for a method for testinginterconnections on PCBs called boundary scan testing.

Access and sampling of boundary scan testing results is typicallylimited to specialized testers that are only employed in In-Circuit Test(ICT). That is, in conventional implementations, test points must beplaced on a PCB and driven by a specialized external ICT tester capableof driving the JTAG connection to achieve boundary scan coverage andconsumption of a Boundary Scan Description Language (BSDL) file.

Aspects of the present disclosure address the above and otherdeficiencies of conventional controller implementations by enablingboundary scan testing using a memory device tester via a UniversalAsynchronous Receiver/Transmitter (UART) connection without requiring anexternal boundary scan connection. A UART host (e.g., standard memorydevice tester) can be connected to a UART of a memory sub-system and canprovide boundary scan test data to a test access port (TAP) controllervia the UART along with a command to initiate boundary scan testing. TheTAP controller, in turn, imitates a boundary scan testing mode using aJTAG interface and synchronously streams a boundary scan test vectorbased on the boundary scan test to an input of a scan chain via the JTAGinterface. The TAP controller provides test result data to the UART hostvia the UART. The test result data is obtained from an output of thescan chain and results from providing the boundary scan test vector asinput to the scan chain.

It shall be appreciated that the testing approach described aboveredirects the typical use case of boundary scan (IEEE 1149.x) from anexternally driven operation to an internally driven operation. Thebenefit of this approach is that it allows for boundary scan testing ofa PCB mounted system without requiring external connections. This is incontrast to classical implementations of boundary scan testing wheretest points must be placed on a PCB and driven by a specialized externaltester capable of driving the JTAG connection to achieve the boundaryscan coverage. This approach further alleviates some PCB space/routingconsiderations by reducing a necessary pin count for facilitatingmultiple modes of testing the controller. Moreover, this approach wouldallow testing to be performed in volume on a regular PCB ATE and wouldnot require additional expense from the ATE hardware, contrary totypical implementations in which boundary scan is performed on a sampledbasis due to the cost of the fixturing and the throughput. Indeed, theimplementation described herein extends the use of a very high coveragetest methodology from a capital-intensive, hardware-only solution to asolution that can be utilized in all systems.

FIG. 1 illustrates an example computing system 100 that includes amemory sub-system 110, in accordance with some embodiments of thepresent disclosure. The memory sub-system 110 can include media, such asone or more volatile memory devices (e.g., memory device 140), one ormore non-volatile memory devices (e.g., memory device 130), or acombination of such.

A memory sub-system 110 can be a storage device, a memory module, or ahybrid of a storage device and memory module. Examples of a storagedevice include a SSD, a flash drive, a universal serial bus (USB) flashdrive, an embedded Multi-Media Controller (eMMC) drive, a UniversalFlash Storage (UFS) drive, a secure digital (SD) card, and a hard diskdrive (HDD). Examples of memory modules include a dual in-line memorymodule (DIMM), a small outline DIMM (SO-DIMM), and various typesnon-volatile dual in-line memory module (NVDIMM).

The computing system 100 can be a computing device such as a desktopcomputer, laptop computer, network server, mobile device, a vehicle(e.g., airplane, drone, train, automobile, or other conveyance),Internet of Things (IoT) enabled device, embedded computer (e.g., oneincluded in a vehicle, industrial equipment, or a networked commercialdevice), or such computing device that includes memory and a processingdevice.

The computing system 100 can include a host system 120 that is coupledto one or more memory sub-systems 110. In some embodiments, the hostsystem 120 is coupled to different types of memory sub-systems 110. FIG.1 illustrates one example of a host system 120 coupled to one memorysub-system 110. As used herein, “coupled to” or “coupled with” generallyrefers to a connection between components, which can be an indirectcommunicative connection or direct communicative connection (e.g.,without intervening components), whether wired or wireless, includingconnections such as electrical, optical, magnetic, and so forth.

The host system 120 can include a processor chipset and a software stackexecuted by the processor chipset. The processor chipset can include oneor more cores, one or more caches, a memory controller (e.g., NVDIMMcontroller), and a storage protocol controller (e.g., PCIe controller,SATA controller). The host system 120 uses the memory sub-system 110,for example, to write data to the memory sub-system 110 and read datafrom the memory sub-system 110.

The host system 120 can be coupled to the memory sub-system 110 via aphysical host interface. Examples of a physical host interface include,but are not limited to, a serial advanced technology attachment (SATA)interface, a peripheral component interconnect express (PCIe) interface,universal serial bus (USB) interface, Fiber Channel, Serial AttachedSCSI (SAS), Small Computer System Interface (SCSI), a double data rate(DDR) memory bus, a dual in-line memory module (DIMM) interface (e.g.,DIMM socket interface that supports Double Data Rate (DDR)), Open NANDFlash Interface (ONFI), Double Data Rate (DDR), Low Power Double DataRate (LPDDR), or any other interface. The physical host interface can beused to transmit data between the host system 120 and the memorysub-system 110. The host system 120 can further utilize an NVM Express(NVMe) interface to access components (e.g., memory devices 130) whenthe memory sub-system 110 is coupled with the host system 120 by thePCIe interface. The physical host interface can provide an interface forpassing control, address, data, and other signals between the memorysub-system 110 and the host system 120. FIG. 1 illustrates a memorysub-system 110 as an example. In general, the host system 120 can accessmultiple memory sub-systems via a same communication connection,multiple separate communication connections, and/or a combination ofcommunication connections.

The memory devices 130,140 can include any combination of the differenttypes of non-volatile memory devices and/or volatile memory devices. Thevolatile memory devices (e.g., memory device 140) can be, but are notlimited to, random access memory (RAM), such as dynamic random accessmemory (DRAM) and synchronous dynamic random access memory (SDRAM).

Some examples of non-volatile memory devices (e.g., memory device 130)includes a NAND type flash memory and write-in-place memory, such as athree-dimensional cross-point (“3D cross-point”) memory device, which isa cross-point array of non-volatile memory cells. A cross-point array ofnon-volatile memory can perform bit storage based on a change of bulkresistance, in conjunction with a stackable cross-gridded data accessarray. Additionally, in contrast to many flash-based memories,cross-point non-volatile memory can perform a write in-place operation,where a non-volatile memory cell can be programmed without thenon-volatile memory cell being previously erased. NAND type flash memoryincludes, for example, two-dimensional NAND (2D NAND) andthree-dimensional NAND (3D NAND)

Each of the memory devices 130 can include one or more arrays of memorycells. One type of memory cell, for example, single level cells (SLC)can store one bit per cell. Other types of memory cells, such asmulti-level cells (MLCs), triple level cells (TLCs), quad-level cells(QLCs), and penta-level cells (PLCs) can store multiple bits per cell.In some embodiments, each of the memory devices 130 can include one ormore arrays of memory cells such as SLCs, MLCs, TLCs, QLCs, or anycombination of such. In some embodiments, a particular memory device caninclude an SLC portion, and an MLC portion, a TLC portion, or a QLCportion of memory cells. The memory cells of the memory devices 130 canbe grouped as pages that can refer to a logical unit of the memorydevice used to store data. With some types of memory (e.g., NAND), pagescan be grouped to form blocks.

Although non-volatile memory components such as NAND type flash memory(e.g., 2D NAND, 3D NAND) and 3D cross-point array of non-volatile memorycells are described, the memory device 130 can be based on any othertype of non-volatile memory, such as read-only memory (ROM), phasechange memory (PCM), self-selecting memory, other chalcogenide basedmemories, ferroelectric transistor random-access memory (FeTRAM),ferroelectric random access memory (FeRAM), magneto random access memory(MRAM), Spin Transfer Torque (STT)-MRAM, conductive bridging RAM(CBRAM), resistive random access memory (RRAM), oxide based. RRAM(OxRAM), NOR flash memory, and electrically erasable programmableread-only memory (EEPROM).

The memory sub-system controller 115 (or controller 115 for simplicity)can communicate with the memory devices 130 to perform operations suchas reading data, writing data, or erasing data at the memory devices 130and other such operations. The memory sub-system controller 115 caninclude hardware such as one or more integrated circuits and/or discretecomponents, a buffer memory, or a combination thereof. The hardware caninclude digital circuitry with dedicated (i.e., hard-coded) logic toperform the operations described herein. The memory sub-systemcontroller 115 can be a microcontroller, special purpose logic circuitry(e.g., a field programmable gate array (FPGA), an application specificintegrated circuit (ASIC), etc.), or other suitable processor.

The memory sub-system controller 115 can include a processor 117(processing device) configured to execute instructions stored in a localmemory 119. In the illustrated example, the local memory 119 of thememory sub-system controller 115 includes an embedded memory configuredto store instructions for performing various processes, operations,logic flows, and routines that control operation of the memorysub-system 110, including handling communications between the memorysub-system 110 and the host system 120.

In some embodiments, the local memory 119 can include memory registersstoring memory pointers, fetched data, and the like. The local memory119 can also include ROM for storing micro-code. While the examplememory sub-system 110 in FIG. 1 has been illustrated as including thememory sub-system controller 115, in another embodiment of the presentdisclosure, a memory sub-system 110 does not include a memory sub-systemcontroller 115, and can instead rely upon external control (e.g.,provided by an external host, or by a processor or controller separatefrom the memory sub-system).

In general, the memory sub-system controller 115 can receive commands oroperations from the host system 120 and can convert the commands oroperations into instructions or appropriate commands to achieve thedesired access to the memory devices 130 and/or the memory device 140.The memory sub-system controller 115 can be responsible for otheroperations such as wear leveling operations, garbage collectionoperations, error detection and error-correcting code (ECC) operations,encryption operations, caching operations, and address translationsbetween a logical address (e.g., logical block address (LBA), namespace)and a physical address (e.g., physical block address) that areassociated with the memory devices 130. The memory sub-system controller115 can further include host interface circuitry to communicate with thehost system 120 via the physical host interface. The host interfacecircuitry can convert the commands received from the host system 120into command instructions to access the memory devices 130 and/or thememory device 140 and convert responses associated with the memorydevices 130 and/or the memory device 140 into information for the hostsystem 120.

The memory sub-system 110 can also include additional circuitry orcomponents that are not illustrated. In some embodiments, the memorysub-system 110 can include a cache or buffer (e.g., DRAM) and addresscircuitry (e.g., a row decoder and a column decoder) that can receive anaddress from the memory sub-system controller 115 and decode the addressto access the memory devices 130.

The memory sub-system 110 can also include additional circuitry orcomponents that are not illustrated. In some embodiments, the memorysub-system 110 can include a cache or buffer (e.g., DRAM) and addresscircuitry (e.g., a row decoder and a column decoder) that can receive anaddress from the memory sub-system controller 115 and decode the addressto access the memory devices 130.

In some embodiments, the memory devices 130 include local mediacontrollers 135 that operate in conjunction with memory sub-systemcontroller 115 to execute operations on one or more memory cells of thememory devices 130. An external controller (e.g., memory sub-systemcontroller 115) can externally manage the memory device 130 (e.g.,perform media management operations on the memory device 130). In someembodiments, a memory device 130 is a managed memory device, which is araw memory device combined with a local controller (e.g., localcontroller 135) for media management within the same memory devicepackage. An example of a managed memory device is a managed NAND (MNAND)device.

The memory sub-system includes a testing sub-system 113 to facilitatetesting of the memory sub-system controller 115. In some embodiments,the memory sub-system controller 115 includes the testing sub-system113. The testing sub-system 113 comprises a universal asynchronousreceiver-transmitter (UART) 114 and a test access point (TAP) controller116. The UART 114 can comprise a physical circuit that is generallyresponsible for transmitting and receiving serial data. To this end, theUART comprises a receiver channel to receive input data and atransmitter channel to transmit output data. In the context of thepresent disclosure, the memory sub-system 110 is on a PCB and thereceiver channel and transmitter channel are exposed on the PCB andexternally accessible to a UART host 104.

The TAP controller 116 may be or comprise a state machine to controloperation of the testing sub-system 113. The TAP controller 116 isconnected to a JTAG interface 124 (also referred to as a “Test AccessPort” or “TAP”). The JTAG interface 124 uses multiple signals in supportof boundary scan testing. For example, the JTAG interface 124 maycomprise: a test clock (TCK) pin to receive a clock signal thatsynchronizes internal state machine operations; a testing mode select(TMS) pin to receive a signal that is sampled at the rising edge of theclock signal to determine a next state; a test data in (TDI) pin toreceive a signal representing data shifted into test or programminglogic of the testing sub-system 113; a test data out (TDO) pin to outputa signal that represents data shifted out of the test or programminglogic; and a test reset pin (TRST) to reset the TAP controller 116 statemachine.

The UART host 104 may be a memory device tester and can be coupled tothe testing sub-system 113 via external connections to the receiverchannel and the transmitter channel exposed on the PCB. The UART host104 can work in conjunction with the testing sub-system 113 to performtesting on the controller 115 to verify the structure and properfunctioning of the controller 115 using boundary scan testing methods.For example, the UART host 104 may provide the testing sub-system 113with boundary scan data, via the receiver channel of the UART 114, alongwith a command to initiate boundary scan testing at the memorysub-system controller 115. Based on receiving the command, the TAPcontroller 116 initiates a boundary scan test mode and synchronouslystreams a boundary scan test vector to a scan chain via the JTAGinterface 124. The boundary scan data may include the boundary scan testvector or a BSDL file from which the boundary scan test vector may bederived by the testing sub-system 113. The testing sub-system 113obtains test result data from an output of the scan chain and providesthe test result data to the UART host 104 via the transmitter channel ofthe UART 114. The test result data is generated as a result of providingthe test vector as input to the scan chain.

The UART host 104 can compare the test result data with datarepresenting an expected result of applying the test vector to the scanchain of the memory sub-system controller 115. The UART host 104 canclassify the test result data as either a positive or negative testresult based on the comparison. A positive test result occurs when testresult data matches the expected result. A negative test result occurswhen test result data does not match the expected result.

The testing sub-system 113 can also include additional circuitry orcomponents to perform various command interpretation, multiplexing, andclocking operations in support of facilitating boundary scan testing viaconnections to the UART 114. The memory sub-system 110 can also includeadditional circuitry or components that are not illustrated. In someembodiments, the memory sub-system 110 can include a cache or buffer(e.g., DRAM) and address circuitry (e.g., a row decoder and a columndecoder) that can receive an address from the memory sub-systemcontroller 115 and decode the address to access the memory devices 130.

Although FIG. 1 illustrates the testing sub-system 113 residing on thememory sub-system controller 115, it shall be appreciated that in otherembodiments, the testing sub-system 113 may reside on the local mediacontroller 135. Further, in some embodiments, a testing sub-system 113may be implemented within both the memory sub-system controller 115 andthe local media controller 135.

FIG. 2 illustrates a process flow for facilitating post-manufactureboundary scan testing of a PCB mounted memory sub-system controller, inaccordance with some embodiments of the present disclosure. To avoidobscuring the inventive subject matter with unnecessary detail, variouscomponents and other details that are not germane to conveying anunderstanding of the inventive subject matter have been omitted fromFIG. 2. As such, a skilled artisan will readily recognize that variousadditional functional components that may be included within the contextof FIG. 2 to facilitate additional functionality that are notspecifically described herein.

As shown, boundary scan test data 200 is received as input on a receiverchannel 202 of the UART 114. As referenced above, the boundary scan testdata 200 can be provided by a device tester corresponding to UART host104. The boundary scan test data 200 can include one or more boundaryscan test vectors or one or more BSDL files from which the testingsub-system 113 can derive one or more boundary scan test vectors. Aboundary scan test vector comprises a bit sequence. The boundary scantest data 200 can, in some embodiments, further include a command toinitiate a boundary scan test. For example, the boundary scan test data200 can comprise a data packet and the command may be included in apacket header while the test vectors or BSDL files are included in thepacket body. In some embodiments, the command can be separately providedby the UART host 104 prior to providing the boundary scan test data 200.

Based on receiving the command, the testing sub-system 113 initiates aboundary scan test mode. The testing sub-system 113 can initiate theboundary scan test mode by asserting a TMS signal on a TMS pin 204 ofthe JTAG interface 124. Once the boundary scan test mode is initiated,the TAP controller 116 synchronously streams a boundary scan test vectorto a scan chain 206 via a TDI pin 208 of the JTAG interface 124. Thetesting sub-system 113 may comprise circuitry or other components toperform various command processing, buffering, and clockingfunctionality to facilitate a boundary scan test. For example, althoughthe JTAG interface 124 includes a TCK pin 210 to receive a clock signal,the TCK pin 210 may not be used in some embodiments. Instead, thetesting sub-system 113 can, in some embodiments, include one or morebuffers that can be used to buffer the boundary scan test vector toprovide a synchronous input signal to the TDI pin 208 based on theboundary scan test data 200 that was provided asynchronously via theUART 114. Accordingly, prior to providing the synchronous input streamto the scan chain 206, the testing sub-system 113 can add one or moreportions of a test vector into one or more buffers.

The scan chain 206 comprises multiple scan cells connected in a chain.Each boundary scan cell comprises a shift-register stage that isconnected between an input or output pin of the memory sub-systemcontroller 115 and application logic to which each pin is normallyconnected. The scan chain 206 has two states of operation. A first stateallows a sequence of bits representing data and instructions to beshifted (scanned-in) into a chain of scan cells, resulting in latchingeach cell to the desired value. A second state of operation involvestesting the application logic. The test operation involves eitherreceiving test data (e.g., a test vector) from the application logic andthen latching the output, or shifting test data into the applicationlogic.

After the scan chain 206 is loaded with bits from the test vector, atest response is captured from an output of the scan chain 206 by thetesting sub-system 113 in one or more clock cycles and test result data220 comprising the test result is provided to the UART host 104 via atransmitter channel 214 of the UART 114. More specifically, as shown,the testing sub-system 113 comprises a dual output multiplexer 216 thatmultiplexes the test response output by the scan chain 206 between a TDOpin 218 of the JTAG interface 124 and the transmitter channel 214 of theUART 114. That is, a first output of the multiplexer 216 is connected tothe TDO pin 218 of the JTAG interface 124 and provides test result data220 thereto while a second output of the multiplexer 216 is connected tothe transmitter channel 214 of the UART 114 and provides the test resultdata 220 thereto.

In some embodiments, an indication that the test result data 220 isforthcoming may be provided to the UART 114 prior to providing the testresult data 220. Depending on the embodiment, the indication may beprovided as part of the test result data 220 (e.g., in a packet header)or may be provided separately from the test result data 220.

FIGS. 3 and 4 are flow diagrams of an example method 300 to facilitatepost-manufacture boundary scan testing of the memory sub-systemcontroller 115, in accordance with some embodiments of the presentdisclosure. The method 300 can be performed by processing logic that caninclude hardware (e.g., processing device, circuitry, dedicated logic,programmable logic, microcode, hardware of a device, integrated circuit,etc.), software (e.g., instructions run or executed on a processingdevice), or a combination thereof. In some embodiments, the method 300is performed by the testing sub-system 113. Although shown in aparticular sequence or order, unless otherwise specified, the order ofthe processes can be modified. Thus, the illustrated embodiments shouldbe understood only as examples, and the illustrated processes can beperformed in a different order, and some processes can be performed inparallel. Additionally, one or more processes can be omitted in variousembodiments. Thus, not all processes are required in every embodiment.Other process flows are possible.

At operation 305, the processing device receives boundary scan test dataand a command to initiate a boundary scan test from a UART host (e.g.,UART host 104). That is, the UART host may provide the boundary scantest data and the command as input to the receiver line of the UART. Thecommand and boundary scan test may be received as an asynchronous packetfrom the UART host via a UART (e.g., UART 114) where, for example, thecommand is included in a packet header. Depending on the embodiment, theboundary scan test data may include one or more boundary scan testvectors or one or more BSDL files.

The processing device initiates a boundary scan mode at operation 310based on receiving the command and synchronously streams a boundary scantest vector to a scan chain (e.g., scan chain 206), at operation 315.The processing device may perform various buffering, multiplexing, andclocking operations to synchronously provide the boundary scan testvector to the scan chain. In embodiments in which the boundary scan testdata includes a BSDL file, the processing device may convert the BSDLfile to the boundary scan test vector.

The scan chain outputs test result data as a result of the boundary scantest vector being input into the scan chain, and the processing deviceobtains the test result data output by the scan chain at operation 320.

At operation 325, the processing device provides, via the UART anindication of forthcoming test result data to the UART host. Theprocessing device provides the test result data to the UART host via theUART at operation 330. That is, the processing device causes the testresult data to be output on the transmitter line of the UART, which isconnected to the UART host. In some embodiments, the indication offorthcoming test result data and the test result data may be provided tothe UART host as a single data packet where, for example, the indicationis included in a packet header.

As shown in FIG. 4, the method 300 may, in some embodiments, includeoperations 400, 405, 410, and 415. Consistent with these embodiments,the operation 400 may be performed as part of (e.g., a sub-operation)operation 310 wherein the processing device initiates a boundary scantest mode. At operation 400, the processing device provides a test modeselect signal to the TMS pin of a JTAG interface (e.g., JTAG interface124). The test mode select signal is based on the boundary scan testdata.

Consistent with these embodiments, the operations 405 and 410 may beperformed as part of (e.g., sub-operations) of operation 315 where theprocessing device synchronously streams the scan test vector to the scanchain. At operation 405, the processing device performs an asynchronousto synchronous conversion of the scan test vector, and at operation 410,the processing device provides the scan test vector as a synchronousinput to a TDI pin of the JTAG interface. Theasynchronous-to-synchronous conversion of the scan test vector maycomprise buffering the boundary scan test vector. That is, theprocessing device may add a portion of the boundary scan test vector(e.g., a byte) to a buffer at each clock cycle and provide the bufferedportion of the boundary scan test vector as input to the TDI pin of theJTAG interface during the next clock cycle, thereby creating a clockedinput signal to the TDI pin.

Consistent with these embodiments, the operation 415 may be performed aspart of the operation 330 (e.g., a sub-operation) where the processingdevice provides the test result data as output to the UART host. Atoperation 415, the processing device multiplexes the test result dataoutput by the scan chain. That is, the processing device multiplexes thetest result data output by the scan chain such that the test result datais provided as output to the transmit channel of the UART. For example,the processing device may utilize a multiplexer with a single input anda dual output. In this example, the input is connected to the output ofthe scan chain and receives the test result data, a first output isconnected to the TDO pin of the JTAG interface, and the second output isconnected to the transmit channel of the UART. The processing device maycontrol the multiplexer such that the test result data provided at themultiplexer input is output to the transmit channel through the secondmultiplexer output.

Examples

Example 1 is a memory sub-system controller comprising: an universalasynchronous receiver-transmitter (UART), the UART to receive, from aUART host, a command to initiate a boundary scan test and boundary scantest data; and a processing device coupled to the UART, processingdevice to perform operations comprising: based on receiving the command,initiating a boundary scan test mode; and synchronously streaming, to ascan chain, a boundary scan test vector based on the boundary scan testdata received at a receiver of the UART; and wherein the UART is furtherto provide test result data output by the scan chain to the UART host,the test result data resulting from synchronously streaming the boundaryscan test vector to the scan chain.

Example 2 comprises the subject matter of Example 1, wherein thesynchronous streaming of the boundary scan test vector to the scan chainoptionally comprises performing an asynchronous-to-synchronousconversion of the boundary scan test vector.

Example 3 comprises the subject matter of any one of Examples 1 and 2,wherein the synchronous streaming of the boundary scan test vector tothe scan chain optionally comprises buffering the boundary scan testvector.

Example 4 comprises the subject matter of any one of Examples 1-3,wherein the synchronous streaming of the boundary scan test vector tothe scan chain optionally comprises adding a portion of the boundaryscan test vector to a buffer during a first clock cycle and providingthe portion of the boundary scan test vector to the scan chain during asecond clock cycle.

In Example 5, the subject matter of any one of Examples 1-4 optionallyfurther comprises: providing a test mode select signal to a test modeselect (TMS) pin of a JTAG interface coupled to the scan chain toinitiate the boundary scan test mode.

In Example 6, the subject matter of any one of Examples 1-5 optionally,further comprises: providing the scan test vector as input to a testdata in (TDI) pin of the JTAG interface.

Example 7 comprises the subject matter of any one of Examples 1-6wherein: the boundary scan test data optionally comprises a BoundaryScan Descriptive Language (BSDL) file, and the processing generates theboundary scan test vector based on the BSDL file.

Example 8 comprises the subject matter of any one of Examples 1-7wherein: the boundary scan test data optionally comprises the boundaryscan test vector.

Example 9 comprises the subject matter of any one of Examples 1-8 andoptionally further comprises a multiplexer having a multiplexer input, afirst multiplexer output and a second multiplexer output, wherein themultiplexer input is connected to an output of the scan chain, the firstmultiplexer output is connected to a test data out (TDO) pin of the JTAGinterface, and the second multiplexer output is connected to the UART,wherein the second multiplexer output provides the test result data tothe UART.

Example 10 comprises the subject matter of any one of Examples 1-9,wherein the UART optionally provides, to the UART host, an indication offorthcoming test result data prior to providing the test result data tothe UART host.

Example 11 is a method comprising: receiving, via a universalasynchronous receiver-transmitter (UART), boundary scan test data and acommand to initiate a boundary scan test from a UART host; and based onreceiving the command, initiating a boundary scan test mode at a memorysub-system controller; synchronously streaming, via a Joint Test ActionGroup (HAG) interface, a boundary scan test vector to a scan chain basedon the boundary scan test data received at a receiver of the UART; andproviding, via the UART, test result data output by the scan chain tothe UART host, the test result data resulting from synchronouslystreaming the boundary scan test vector to the scan chain.

Example 12 comprises the subject matter of Example 11, wherein thesynchronous streaming of the boundary scan test vector to the scan chainoptionally comprises performing an asynchronous-to-synchronousconversion of the boundary scan test vector.

Example 13 comprises the subject matter of any one of Examples 11 or 12,wherein the synchronous streaming of the boundary scan test vector tothe scan chain optionally comprises buffering the boundary scan testvector.

Example 14 comprises the subject matter of any one of Examples 11-13,wherein the synchronous streaming of the boundary scan test vector tothe scan chain optionally comprises adding a portion of the boundaryscan test vector to a buffer during a first clock cycle and providingthe portion of the boundary scan test vector to the scan chain during asecond clock cycle.

In Example 15, the subject matter of any one of Examples 11-14optionally further comprises: providing a test mode select signal to atest mode select (TMS) pin of a JTAG interface coupled to the scan chainto initiate the boundary scan test mode.

In Example 16, the subject matter of any one of Examples 11-15optionally further comprises: providing the scan test vector as input toa test data in (TDI) pin of the JTAG interface.

Example 17 comprises the subject matter of any one of Examples 11-16wherein: the boundary scan test data optionally comprises a BoundaryScan Descriptive Language (BSDL) file, and the processing generates theboundary scan test vector based on the BSDL file.

Example 18 comprises the subject matter of any one of Examples 11-17wherein: the boundary scan test data optionally comprises the boundaryscan test vector.

Example 19 comprises the subject matter of any one of Examples 11-19,wherein the UART optionally provides, to the UART host, an indication offorthcoming test result data prior to providing the test result data tothe UART host.

Example 20 is a system comprising: A non-transitory computer-readablestorage medium comprising instructions that, when executed by aprocessing device, configure the processing device to perform operationscomprising: receiving, via a universal asynchronous receiver-transmitter(UART), boundary scan test data and a command to initiate a boundaryscan test from a UART host; and based on receiving the command,initiating a boundary scan test mode at a memory sub-system controller;synchronously streaming, via a Joint Test Action Group (JTAG) interface,a boundary scan test vector to a scan chain based on the boundary scantest data received at a receiver of the UART; and providing, via theUART, test result data output by the scan chain to the UART host, thetest result data resulting from synchronously streaming the boundaryscan test vector to the scan chain.

FIG. 5 illustrates an example machine in the form of a computer system500 within which a set of instructions can be executed for causing themachine to perform any one or more of the methodologies discussedherein. In some embodiments, the computer system 500 can correspond to ahost system (e.g., the host system 120 of FIG. 1) that includes, iscoupled to, or utilizes a memory sub-system (e.g., the memory sub-system110 of FIG. 1) or can be used to perform the operations of a controller(e.g., to execute an operating system to perform operationscorresponding to the testing sub-system 113 of FIG. 1). In alternativeembodiments, the machine can be connected (e.g., networked) to othermachines in a local area network (LAN), an intranet, an extranet, and/orthe Internet. The machine can operate in the capacity of a server or aclient machine in client-server network environment, as a peer machinein a peer-to-peer (or distributed) network environment, or as a serveror a client machine in a cloud computing infrastructure or environment.

The machine can be a personal computer (PC), a tablet PC, a set-top box(STB), a Personal Digital Assistant (PDA), a cellular telephone, a webappliance, a server, a network router, a switch or bridge, or anymachine capable of executing a set of instructions (sequential orotherwise) that specify actions to be taken by that machine. Further,while a single machine is illustrated, the term “machine” shall also betaken to include any collection of machines that individually orjointly, execute a set (or multiple sets) of instructions to perform anyone or more of the methodologies discussed herein.

The example computer system 500 includes a processing device 502, a mainmemory 504 (e.g., ROM, flash memory, DRAM such as SDRAM or Rambus DRAM(RDRAM), etc.), a static memory 506 (e.g., flash memory, static randomaccess memory (SRAM), etc.), and a data storage system 518, whichcommunicate with each other via a bus 530.

The processing device 502 represents one or more general-purposeprocessing devices such as a microprocessor, a central processing unit,or the like. More particularly, the processing device 502 can be acomplex instruction set computing (CISC) microprocessor, a reducedinstruction set computing (RISC) microprocessor, a very long instructionword (VLIW) microprocessor, a processor implementing other instructionsets, or processors implementing a combination of instruction sets. Theprocessing device 502 can also be one or more special-purpose processingdevices such as an ASIC, an FPGA, a digital signal processor (DSP), anetwork processor, or the like. The processing device 502 is configuredto execute instructions 526 for performing the operations and stepsdiscussed herein. The computer system 500 can further include a networkinterface device 508 to communicate over a network 520.

The data storage system 518 can include a machine-readable storagemedium 524 (also known as a computer-readable medium) on which is storedone or more sets of instructions 526 or software embodying any one ormore of the methodologies or functions described herein. Theinstructions 526 can also reside, completely or at least partially,within the main memory 504 and/or within the processing device 502during execution thereof by the computer system 500, the main memory 504and the processing device 502 also constituting machine-readable storagemedia. The machine-readable storage medium 524, data storage system 518,and/or main memory 504 can correspond to the memory sub-system 110 ofFIG. 1.

In one embodiment, the instructions 526 include instructions toimplement functionality corresponding to a security component (e.g., thetesting sub-system 113 of FIG. 1). While the machine-readable storagemedium 524 is shown in an example embodiment to be a single medium, theterm “machine-readable storage medium” should be taken to include asingle medium or multiple media that store the one or more sets ofinstructions. The term “machine-readable storage medium” shall also betaken to include any medium that is capable of storing or encoding a setof instructions for execution by the machine and that cause the machineto perform any one or more of the methodologies of the presentdisclosure. The term “machine-readable storage medium” shall accordinglybe taken to include, but not be limited to, solid-state memories,optical media, and magnetic media.

Some portions of the preceding detailed descriptions have been presentedin terms of algorithms and symbolic representations of operations ondata bits within a computer memory. These algorithmic descriptions andrepresentations are the ways used by those skilled in the dataprocessing arts to most effectively convey the substance of their workto others skilled in the art. An algorithm is here, and generally,conceived to be a self-consistent sequence of operations leading to adesired result. The operations are those requiring physicalmanipulations of physical quantities. Usually, though not necessarily,these quantities take the form of electrical or magnetic signals capableof being stored, combined, compared, and otherwise manipulated. It hasproven convenient at times, principally for reasons of common usage, torefer to these signals as bits, values, elements, symbols, characters,terms, numbers, or the like.

It should be borne in mind, however, that all of these and similar termsare to be associated with the appropriate physical quantities and aremerely convenient labels applied to these quantities. The presentdisclosure can refer to the action and processes of a computer system,or similar electronic computing device, that manipulates and transformsdata represented as physical (electronic) quantities within the computersystem's registers and memories into other data similarly represented asphysical quantities within the computer system's memories or registersor other such information storage systems.

The present disclosure also relates to an apparatus for performing theoperations herein. This apparatus can be specially constructed for theintended purposes, or it can include a general-purpose computerselectively activated or reconfigured by a computer program stored inthe computer. Such a computer program can be stored in acomputer-readable storage medium, such as, but not limited to, any typeof disk including floppy disks, optical disks, CD-ROMs, andmagnetic-optical disks; ROMs; RAMs; erasable programmable read-onlymemories (EPROMs); EEPROMs; magnetic or optical cards; or any type ofmedia suitable for storing electronic instructions, each coupled to acomputer system bus.

The algorithms and displays presented herein are not inherently relatedto any particular computer or other apparatus. Various general-purposesystems can be used with programs in accordance with the teachingsherein, or it can prove convenient to construct a more specializedapparatus to perform the method. The structure for a variety of thesesystems will appear as set forth in the description above. In addition,the present disclosure is not described with reference to any particularprogramming language. It will be appreciated that a variety ofprogramming languages can be used to implement the teachings of thedisclosure as described herein.

The present disclosure can be provided as a computer program product, orsoftware, that can include a machine-readable medium having storedthereon instructions, which can be used to program a computer system (orother electronic devices) to perform a process according to the presentdisclosure. A machine-readable medium includes any mechanism for storinginformation in a form readable by a machine (e.g., a computer). In someembodiments, a machine-readable (e.g., computer-readable) mediumincludes a machine-readable (e.g., a computer-readable) storage mediumsuch as a ROM, a RAM, magnetic disk storage media, optical storagemedia, flash memory components, and so forth.

In the foregoing specification, embodiments of the disclosure have beendescribed with reference to specific example embodiments thereof. Itwill be evident that various modifications can be made thereto withoutdeparting from the broader scope of embodiments of the disclosure as setforth in the following claims. The specification and drawings are,accordingly, to be regarded in an illustrative sense rather than arestrictive sense.

1. A memory sub-system controller comprising: a universal asynchronousreceiver-transmitter (UART), the UART to receive, from a UART host, acommand to initiate a boundary scan test and boundary scan test data; aprocessing device coupled to the UART, the processing device to performoperations comprising: based on receiving the command, initiating aboundary scan test mode; and synchronously streaming, to a scan chaincomprising a plurality of scan cells, a boundary scan test vector basedon the boundary scan test data received at the UART, a multiplexerhaving an multiplexer input, a first multiplexer output and a secondmultiplexer output, the multiplexer input being connected to an outputof the scan chain, the first multiplexer output being connected to atest data out (TDO) element of a JTAG interface, the second multiplexeroutput being connected to the UART, the second multiplexer outputproviding test result data to the UART, the test result data resultingfrom synchronously streaming the boundary scan test vector to the scanchain, the UART providing the test result data to the UART host.
 2. Thememory sub-system controller of claim 1, wherein the synchronousstreaming of the boundary scan test vector to the scan chain comprisesperforming an asynchronous-to-synchronous conversion of the boundaryscan test vector.
 3. The memory sub-system controller of claim 2,wherein performing the asynchronous-to-synchronous conversion of theboundary scan test vector comprises buffering the boundary scan testvector.
 4. The memory sub-system controller of claim 3, wherein thememory sub-system controller comprises a buffer, wherein the bufferingof the boundary scan test vector comprising adding a portion of theboundary scan test vector to the buffer during a first clock cycle andproviding the portion of the boundary scan test vector to the scan chainduring a second clock cycle.
 5. The memory sub-system controller ofclaim 1, wherein the initiating of the boundary scan test modecomprises: providing a test mode select signal to a test mode select(TMS) pin of a Joint Test Action Group (JTAG) interface coupled to thescan chain.
 6. The memory sub-system controller of claim 5, whereinstreaming the boundary scan test vector to a scan chain comprises:providing the scan test vector as input to a test data in (TDI) pin ofthe JTAG interface.
 7. The memory sub-system controller of claim 1,wherein: the boundary scan test data comprises a Boundary ScanDescriptive Language (BSDL) file; and the processing device generatesthe boundary scan test vector based on the BSDL file.
 8. The memorysub-system controller of claim 7, wherein: the boundary scan test datacomprises the boundary scan test vector generated based on a BSDL file.9. The memory sub-system controller of claim 1, wherein the processingdevice causes the multiplexer to output the test result data at thesecond multiplexer output to a transmit channel of the UART.
 10. Thememory sub-system controller of claim 1, wherein the UART provides, tothe UART host, an indication of forthcoming test result data prior toproviding the test result data to the UART host.
 11. A methodcomprising: receiving, via a universal asynchronous receiver-transmitter(UART), boundary scan test data and a command to initiate a boundaryscan test from a UART host; based on receiving the command, initiating aboundary scan test mode at a memory sub-system controller; synchronouslystreaming, via a Joint Test Action Group (JTAG) interface, a boundaryscan test vector to a scan chain based on the boundary scan test datareceived at a receiver of the UART; multiplexing, by a multiplexer, testresult data output by the scan chain, the test result data beingmultiplexed such that the test result data is provided to a transmitchannel of the UART, the test result data resulting from synchronouslystreaming the boundary scan test vector to the scan chain; andproviding, via the UART, the test result data output by the scan chainto the UART host.
 12. The method of claim 11, wherein the synchronousstreaming of the boundary scan test vector to the scan chain comprisesperforming an asynchronous-to-synchronous conversion of the boundaryscan test vector.
 13. The method of claim 12, wherein performing theasynchronous-to-synchronous conversion of the boundary scan test vectorcomprises buffering the boundary scan test vector.
 14. The method ofclaim 13, wherein the buffering of the boundary scan test vectorcomprises adding a portion of the boundary scan test vector to a bufferduring a first clock cycle and providing the portion of the boundaryscan test vector to the scan chain during a second clock cycle.
 15. Themethod of claim 11, wherein the initiating of the boundary scan testmode comprises: providing a test mode select signal to a test modeselect (TMS) pin of a the JTAG interface coupled to the scan chain 16.The method of claim 15, wherein streaming the boundary scan test vectorcomprises: providing the scan test vector as input to a test data in(TDI) pin of the JTAG interface.
 17. The method of claim 11, furthercomprising generating the boundary scan test vector based on a BSDL fileincluded in the boundary scan test data.
 18. The method of claim 11,wherein: the boundary scan test data comprises the boundary scan testvector.
 19. The method of claim 11, further comprising providing, to theUART host, an indication of forthcoming test result data prior toproviding the test result data to the UART host.
 20. A non-transitorycomputer-readable storage medium comprising instructions that, whenexecuted by a processing device, configure the processing device toperform operations comprising: receiving, via a universal asynchronousreceiver-transmitter (UART), boundary scan test data and a command toinitiate a boundary scan test from a UART host; initiating a boundaryscan test mode at a memory sub-system controller based on receiving thecommand; synchronously providing, via a Joint Test Action Group (JTAG)interface, a boundary scan test vector to a scan chain based on theboundary scan test data received at a receiver of the UART; andmultiplexing test result data output by the scan chain, the test resultdata being multiplexed such that the test result data is provided to atransmit channel of the UART, the test result data resulting fromsynchronously streaming the boundary scan test vector to the scan chain;and providing, via the UART, the test result data output by the scanchain to the UART host.